AI Engineering，可以簡單理解成：把 AI 從「會回答問題的模型」，變成「可以穩定放進產品裡使用的能力」。

做一個 AI Demo 很容易。只要接上模型 API、寫 Prompt，就能做出摘要、問答、分類或自動化功能。但真正的產品不能只要求「大部分時候看起來可以」。它還要面對模型回答不穩定、格式錯誤、找錯資料、執行太慢、成本過高、服務中斷，以及使用者回報錯誤時無法追查原因等問題。

因此，AI Engineering 不只是研究模型本身，而是處理整個 AI 應用系統，包括模型怎麼使用、資料怎麼提供、工作流程怎麼設計、AI 能使用哪些工具、失敗時怎麼處理，以及如何測試、記錄和改善品質。

它和傳統軟體工程最大的差別，是 AI 的結果具有不確定性。一般程式只要規則正確，結果通常可以預期；但 AI 即使收到相同問題，也可能產生不同答案。因此 AI 產品除了測試程式有沒有 Bug，還必須評估回答品質、資料是否正確、工具是否被正確使用，以及整個執行過程是否可以追蹤。

如果沒有 AI Engineering，產品通常不會立刻失敗，反而可能一開始進展很快。但隨著 Prompt、RAG、工具和 Agent 越來越多，系統會逐漸變得難以理解。回答錯誤時不知道問題出在哪裡，修改一個 Prompt 也不知道其他功能是否受到影響，最後團隊只能靠人工測試和感覺維護產品。

所以 AI Engineering 的目的不是讓所有事情都交給 AI，而是讓傳統軟體負責明確、可計算的事情，讓 AI 處理需要理解、判斷與生成的部分，再用工程方法把兩者可靠地組合起來。

AI Engineering 就是把「聰明但不完全可靠的 AI」，變成「可測試、可控制、可維護，而且能真正服務使用者的產品能力」。

30天的內容先分幾個階段，每個階段都設定一個里程碑，檢視自己的學習計畫成果。

期望在 30 天後，面對一個新的 AI 產品，我可以判斷出：

• 哪些部分真的需要 AI？
• 哪些應該使用 deterministic software？
• Model 在整個 architecture 的哪一層？
• AI 執行時需要哪些 Context？
• 資料怎麼取得？
• 是否需要 RAG？
• Workflow 是否可以預先定義？
• 是否真的需要 Agent？
• Agent 可以使用哪些 Tools？
• State 存在哪？
• Failure 時怎麼 recovery？
• 怎麼測試 AI 品質？
• 怎麼知道修改後變好了？
• 怎麼 Trace 一次 execution？
• Cost 與 latency 可以接受嗎？
• Security boundary 在哪？
• 如果換 Model，需要改多少系統？
• 哪些模組下一個產品可以直接 reuse？
  ....

或者即使我無法馬上有答案，也能知道如何找方法及解決的方向。